The ContextVar.reset(token) in a finally block of an async generator is a subtle footgun — asyncio's context inheritance means a generator can be resumed in a different context from where it was created, so the token from the original context is stale by the time finally runs. Using ContextVar.set(None) as the cleanup instead is the right fix. Does this also affect non-streaming uses of DeepCrawlDecorator, or was it only triggered by the StreamingResponse path?

Good question — the fix covers both paths:

1. Streaming path (line 35) — this is where the bug was triggered in practice, because the async generator's finally block runs in Starlette's consumer Task (different Context).

2. Batch/non-streaming path (line 41) — we fixed this too, even though it's less likely to trigger in practice. The batch path uses a try/finally (not a generator), so reset(token) would typically work since the finally runs in the same coroutine. However, if the calling code ever wraps the batch call in asyncio.create_task() or runs it from a copied context, the same bug would surface. We applied set(False) there as well for consistency and safety.

Also, a small note: we use set(False) (not set(None)) since the ContextVar's default is False and the guard checks not self.deep_crawl_active.get().